&%55$ssolhggwrr'hyhorsphqwwzlwkk5hxvhh%dvhggrqq0hfdqrvv 0hfdqrv$q2yhuylhz

ion levels, called reusable assets, these elements have to be stored in an adequate repository [4,5]. The supported abstraction levels are requirements level, design level and implementation level. Around the a reuse model has been defined, which is articulated over three edges, the technical model, the process model and the qualification model. The technical reuse model presents a duality compositional/generative in the creation of . Firstly, can be built as composition of individual reusable assets based on their relationships. This operation is a typical development-for-reuse activity; the result of which is a reusable element that can be reused “as-is” in a development-with-reuse activity. However, when a does not match the reuser’ specifications it cannot be reused “as-is”, consequently a can be generated by composition of the assets stored in the repository, following the relationships among the assets, so the generative approach is a development-with-reuse activity. The core model is presented in Figure 1, using UML 1.3 as modelling language [15]. It presents the main components of this structure: the assets and their relationships. The assets are the reuse-centred components, while the relationships build up the layer for automated retrieval processes through an entry point (usually an asset representing functional requirements) and trace ability across the assets mesh. Both the assets and the relationships must have a type that represents the share properties of these kind of assets or relationships. Due to the different abstraction levels supported by a , there are two kinds of relationship between reusable assets: the relationships – among reusable assets classified in the same abstraction level – and the relationships – among assets classified in different abstraction levels. In this framework, a coarsegrained reusable software element can be considered as a , if it incorporates . The “reuse process” covers every activity, resource or procedure related to the organization’s reuse policy. This model defines the activities to be carried out during the development-for-reuse and development-with-reuse 1 A complete description of the model appears in [4]. Figure 1 presents only an informal model described using UML class notation. [4] presents a formal model based on a graph grammar constructed with tube graphs. processes. Figure 2 defines the basic development-withreuse life-cycle, which will be used to present the novel software engineering reuse model introduced in this paper. Through the retrieval activity, potential , satisfying reuser’s requirements, are searched and selected from the repository. However, not always a retrieved can be reused as a black box, it could be adapted to customize it to a particular requirements of an application. Finally, the selected for reuse should be reassembled to build the subsystems of the final software product. Mecanos as Reusable Components Customized Mecanos Mecanos Specific Applications 5HWULHYDO